AWS Summit Bangkok 2024: ยกระดับความน่าเชื่อถือด้วยโครงสร้างแบบ multi-region

เนื้อหาในบทความนี้สรุปมาจาก Session [Resilience redefined: Building multi-region architectures on AWS] ในงาน AWS Summit Bangkok 2024

Multi-Region และ Disaster Recovery

โดยปกติแล้วหนึ่งในจุดประสงค์หลักของการสร้าง multi-region architectures ก็เพื่อการทำ disaster recovery ในกรณีที่เกิดเหตุการณ์ region failure ขึ้นครับ ถึงแม้โดยปกติแล้วเหตุการณ์ region failure จะมีโอกาสเกิดขึ้นน้อยมาก แต่สำหรับ workload ที่มีความสำคัญสูงมาก ๆ นั้น โอกาสเกิด region failure นั้นต่อให้น้อยแค่ไหน ก็เป็นสิ่งที่ไม่สามารถมองข้ามได้ครับ

หลักการคร่าว ๆ ของการทำ disaster recovery คือการย้าย workload ไปยังอีก region หนึ่ง เมื่อเกิด region failure ขึ้น โดยการทำ disaster recovery นั้นสามารถทำได้หลายวิธี ขึ้นอยู่กับความต้องการต่าง ๆ เช่น RTO, RPO หรือค่าใช้จ่ายเป็นต้น

RPO vs RTO

RPO และ RTO เป็นหนึ่งในปัจจัยสำคัญที่ต้องคำนึงถึงในการทำ disaster recovery ซึ่งโดยปกติแล้วเราจะใช้ RPO และ RTO เป็นตัวตั้ง เพื่อดูว่า workload ของเราควรจะทำ disaster recovery ด้วยวิธีไหน

RPO (Recovery Point Objective)

RPO หมายถึง ระยะเวลาสูงสุดที่เรายอมให้มีการสูญเสียข้อมูลเกิดขึ้นได้เมื่อเกิดเหตุ disaster ขึ้น

โดยปกติแล้วใน workload ใด ๆ จะแบ่งส่วนของ application กับ data แยกกัน โดยที่ data นั้นจะมีการอัปเดตเปลี่ยนแปลงอยู่ตลอดเวลา RPO จะเป็นตัวบ่งชี้ที่เจาะจงไปที่ส่วนของ data นี้โดยเฉพาะครับ

ในการทำ disaster recovery เป็นเรื่องปกติที่เราจะต้องการกู้ workload รวมถึง data ต่าง ๆ ใน workload ให้เป็นข้อมูลปัจจุบันที่สุดเท่าที่จะเป็นไปได้ ซึ่งโดยพื้นฐานแล้วการทำ disaster recovery ในส่วนของ data นั้น จะทำโดยการ copy backup ล่าสุดของ data ดังกล่าวไปยัง region ปลายทาง แล้วสร้าง database ต่าง ๆ ขึ้นมาจาก backup นั้น หมายความว่ายิ่งเราทำ backup ถี่มากเท่าไหร่ data หลังจากทำ disaster recovery ก็จะยิ่งมีความสดใหม่มากเท่านั้น แต่ก็จะแลกมาด้วยค่าใช้จ่ายที่เพิ่มขึ้นด้วยเช่นกัน

RTO (Recovery Time Objective)

RTO หมายถึง ระยะเวลาที่ใช้ในการทำ disaster recovery จนกระทั่ง workload สามารถกลับมาใช้งานได้ตามปกติ (หรือก็คือระยะเวลาที่ใช้ในการย้าย workload ไปยังอีก region หนึ่ง)

ปกติแล้วการเตรียม workload ในอีก region หนึ่งนั้นจะประกอบไปด้วยขั้นตอนต่าง ๆ เช่น การเตรียม infrastructure, การติดตั้ง application ลงบน infrastructure, การจัดการข้อมูล database ต่าง ๆ เป็นต้น โดยเราสามารถเลือกได้ว่าจะเตรียมพร้อมขั้นตอนต่าง ๆ เหล่านี้ตั้งแต่ก่อนเกิด disaster หรือจะเริ่มเตรียมขั้นตอนเหล่านี้หลังจากที่ disaster เกิดขึ้นแล้ว โดยระยะเวลาและค่าใช้จ่ายที่จำเป็นในการทำ disaster recovery ก็จะแตกต่างกันไปครับ

วิธีการทำ Disaster Recovery

อย่างที่กล่าวไปด้านบน การทำ disaster recovery นั้นสามารถทำได้หลายวิธี ขึ้นอยู่กับองค์ประกอบต่าง ๆ เช่น RTO, RPO หรือค่าใช้จ่าย โดย AWS ได้มอบวิธีการทำ disaster recovery ไว้ 4 วิธีที่แตกต่างกันครับ

Backup & Restore

เป็นวิธีการที่เรียบง่ายที่สุด นั่นคือ ใน region ปลายทางนั้น เราจะไม่เตรียมอะไรไว้เลยครับ สิ่งที่เราจะทำมีเพียงแค่อย่างเดียว คือ การทำ backup ให้กับข้อมูลใน region ต้นทางเท่านั้น

ก่อนเกิด disaster
region ต้นทาง	region ปลายทาง
1. ทำ backup ให้กับ data เป็นระยะ ๆ	ไม่ทำอะไร
หลังเกิด disaster
region ต้นทาง	region ปลายทาง
แตก!!	1. สร้าง architecture สำหรับ workload
	2. ติดตั้ง application และ dependencies ต่าง ๆ ที่จำเป็นสำหรับ workload
	3. สร้าง database ต่าง ๆ จาก backup ที่ copy มาจาก region ต้นทาง
	4. สลับ user ให้ไปใช้ region ปลายทาง

วิธี Backup & Restore เหมาะในกรณีที่สามารถรับเงื่อนไขต่อไปนี้ได้

• RPO/RTO: หลักชั่วโมง
• ค่าใช้จ่าย: ต่ำ

Pilot Light

Pilot Light จะต่อยอดมาจากวิธี Backup & Restore เพื่อลด RTO/RPO ให้ต่ำลง โดยนอกเหนือจากการทำ backup ข้อมูลแล้ว ยังมีสิ่งที่ต้องทำเพิ่มขึ้นมาอีกอย่างหนึ่งก็คือ การสร้าง infrastructure สำหรับ workload เตรียมไว้ใน region ปลายทางครับ

เนื่องจากโดยทั่วไป ขั้นตอนการสร้าง infrastructure สำหรับ workload นั้นเป็นขั้นตอนที่กินเวลามากที่สุด (การสร้าง infrastructure ในที่นี้หมายถึงตั้งแต่เริ่มสร้างตัว server, load balancer, etc. ขึ้นมา และติดตั้ง application, dependencies ต่าง ๆ จนอยู่ในสถานะพร้อมใช้งาน) วิธี Pilot Light จึงทำการสร้าง infrastructure เหล่านี้เตรียมไว้ใน region ปลายทาง เพื่อร่นระยะเวลาในการทำ disaster recovery ลงครับ

แต่ infrastructure ที่สร้างขึ้นมาใน region ปลายทางนั้นเราจะยังไม่เปิดใช้งานครับ เพื่อลดค่าใช้จ่ายจากการเปิด server ทิ้งไว้ แต่สิ่งที่ต้องแลกมาก็คือเมื่อถึงเวลาทำ disaster recovery จะต้องใช้เวลาซักระยะหนึ่งเพื่อเปิดใช้งาน infrastructure เหล่านี้ ถึงแม้จะใช้เวลาน้อยเมื่อเทียบกับวิธี Backup & Restore ที่ต้องเริ่มตั้งแต่การสร้าง infrastructure ขึ้นมาตั้งแต่ต้น แต่ก็ยังใช้ระยะเวลาอยู่พอสมควรครับ

และในส่วนของการทำ backup ข้อมูลนั้น ตั้งแต่วิธี Pilot Light เป็นต้นไป เนื่องจากทั้งสอง regions มีการสร้าง infrastructure ไว้พร้อมอยู่แล้ว การทำ backup จะเปลี่ยนไปใช้ความสามารถในการทำ asynchronous cross-region replication ของ database ในการคอย sync ข้อมูลระหว่างทั้งสอง regions แทนครับ และเนื่องจากการ sync ข้อมูลนี้เป็นแบบ asynchronous หมายความว่าจะไม่ใช่ real-time ครับ นั่นคือยังมี RPO เกิดขึ้นอยู่ ขึ้นอยู่กับความถี่ในการ sync ข้อมูล

ก่อนเกิด disaster
region ต้นทาง	region ปลายทาง
1. sync ข้อมูลระหว่าง 2 regions เป็นระยะ ๆ	1. สร้าง infrastructure สำหรับ workload เตรียมไว้ให้พร้อม แต่ยังไม่เปิดใช้งาน
หลังเกิด disaster
region ต้นทาง	region ปลายทาง
แตก!!	1. เปิดใช้งาน infrastructure สำหรับ workload ที่สร้างเตรียมไว้
	2. promote database ให้เป็น database ตัวหลักสำหรับ workload แทน database ตัวเก่า
	3. สลับ user ให้ไปใช้ region ปลายทาง

วิธี Pilot Light เหมาะในกรณีที่สามารถรับเงื่อนไขต่อไปนี้ได้

• RPO/RTO: หลัก 10 นาที
• ค่าใช้จ่าย: ปานกลาง

Warm Standby

Warm Standby คล้ายกับวิธี Pilot Light ครับ แต่จะต่างกันตรงที่ วิธี Pilot Light นั้น จะไม่มีการเปิดใช้งาน infrastructure ใน region ปลายทางเตรียมเอาไว้ (ค่อยเปิดตอนทำ disaster recovery) แต่วิธี Warm Standby จะเปิดใช้งาน infrastructure ใน region ปลายทางเตรียมไว้ครับ แต่เปิดไว้แค่ประมาณ 50% ของ full-load เพื่อไม่ให้ค่าใช้จ่ายบานปลายเกินเหตุ

จุดประสงค์ของการทำแบบนี้ คือเพื่อลด RTO/RPO ลงไปอีก โดยเมื่อเกิด disaster ขึ้น จะสามารถทำ disaster recovery และสลับ user บางส่วนไปที่ region ปลายทางได้ทันที และในระหว่างนั้นก็ค่อย ๆ เปิดใช้งาน infrastructure ที่เหลือจนสามารถรับ full-load ได้

ก่อนเกิด disaster
region ต้นทาง	region ปลายทาง
1. sync ข้อมูลระหว่าง 2 regions เป็นระยะ ๆ	1. สร้าง infrastructure สำหรับ workload เตรียมไว้ให้พร้อม แต่เปิดใช้งานเพียงแค่ครึ่งเดียว
หลังเกิด disaster
region ต้นทาง	region ปลายทาง
แตก!!	1. สลับ user ให้ไปใช้ region ปลายทาง
	2. เปิดใช้งาน infrastructure สำหรับส่วนที่เหลือที่ได้สร้างเตรียมไว้ก่อนหน้า

วิธี Warm Standby เหมาะในกรณีที่สามารถรับเงื่อนไขต่อไปนี้ได้

• RPO/RTO: หลักนาที
• ค่าใช้จ่าย: สูง

Multi-Site Active/Active

Multi-Site Active/Active เป็นวิธีที่ต่อยอดจาก Warm Standby ขึ้นไปอีกขั้นด้วยการเปิดใช้งาน infrastructure ใน region ปลายทางแบบ 100% ไม่มีกั๊กทั้งสิ้นครับ อีกทั้ง infrastructure ในแต่ละ region ยังมีขนาดมากพอที่จะรองรับ full-load ได้ ทำให้วิธี Multi-Site Active/Active สามารถทำ disaster recovery ได้แบบ real-time เลยครับ

สำหรับ infrastructure ใน region ปลายทางนั้น หลาย ๆ คนก็มีความเห็นต่างกันไปครับ บางคนจะไม่ปล่อยให้ user ได้ใช้งาน application ใน region ปลายทางเลยจนกว่าจะมีการทำ disaster recovery แต่บางคนก็มองว่า ไหน ๆ ก็สร้าง infrastructure ที่พร้อมใช้งานไว้แล้ว จะแบ่ง user บางส่วนมาที่ region ปลายทางบ้างก็ไม่เห็นเป็นไร ซึ่งจะใช้งานแบบไหนก็แล้วแต่ที่สะดวกเลยครับ

Multi-Site Active/Active เป็นวิธีที่เหมาะกับ application ที่มีความสำคัญสูงมาก ในระดับที่เราสามารถแลกได้ทุกอย่างเพื่อไม่ให้เกิด downtime ขึ้น เนื่องจากเป็นวิธีที่มีค่าใช้จ่ายสูงมาก และสูงที่สุดในบรรดา 4 วิธีที่ได้นำมาแนะนำไว้ในบทความนี้ด้วย

ก่อนเกิด disaster
region ต้นทาง	region ปลายทาง
1. sync ข้อมูลระหว่าง 2 regions แบบ real-time	1. สร้าง infrastructure สำหรับ workload ขึ้น (ขนาดรองรับ full-load ได้) และเปิดให้ user ใช้งานตามปกติ
หลังเกิด disaster
region ต้นทาง	region ปลายทาง
แตก!!	1. สลับ user ทั้งหมดให้ไปใช้ region ปลายทาง

วิธี Multi-Site Active/Active เหมาะในกรณีที่สามารถรับเงื่อนไขต่อไปนี้ได้

• RPO/RTO: 0 (Real-time)
• ค่าใช้จ่าย: โคตรสูง

สุดท้ายนี้

การสร้าง multi-region architectures เพื่อทำ disaster recovery นั้น หลังจากคำนึงถึงความต้องการ เลือกวิธีที่เหมาะสม และทำการ implement เรียบร้อยแล้ว สิ่งที่สำคัญอีกอย่างหนึ่งก็คือการทดสอบระบบการ failover อยู่เป็นระยะ ๆ เพื่อให้มั่นใจว่าเมื่อถึงคราวจำเป็นจริง ๆ ระบบของเราจะสามารถทำงานตามที่เราคาดหวังไว้ได้ครับ

อ้างอิง

1. Disaster Recovery (DR) objectives - Reliability Pillar
2. Disaster recovery options in the cloud - Disaster Recovery of Workloads on AWS: Recovery in the Cloud